1. Field of the Invention
The present invention relates to the field of provisioning of electronic computing resources via a network to a client, and in particular to a method and system for selecting resource combinations in an infrastructure comprising an application environment consisting of a given resource combination and a resource managing component having access to a list of successfully working combinations.
2. Description of the Related Art
A prior art software product which implements the above prior art method is commercially available and sold by IBM under the product name System Automation for OS/390, version 2.2, since the year 2002. The tool implemented therein is usable basically for application providers, who offer some business application which can be run by a client via a respective adapted network connection. In such use a pool of computing resources, further referred to as resources only, is configured in one or more distinct configurations, which are each able to build up a respective application environment at the server side for the client, in order to make the client run a business application via the network.
A second field of use is found in larger enterprise networks, in which one or more application environments are defined for a person or a group of persons, who also use the above-mentioned resources in order to do their job.
Generally, a resource is to be understood here as any computing entity that can be shared between some users. A resource can be a computing server, some storage unit, some quantity of business data, some quantity of software, a file system, etc., thus including physical entities and logical entities. In many cases a physical entity resource comprises some computing hardware, some operating system, possibly some middleware and some application software.
An application environment as referred to herein is to be understood as a logical collection of resources that are able to provide some specific service, for example to run some business application in the above sense.
A resource manager is understood thereby as a software component running on a respective server for managing one or more resources in the above sense and which is able to instantiate a combination of available resources for a given application environment, to reserve, free and configure resource combinations. A resource combination can, for example, be built up by the following components: (1) an IBM S/390 or zSeries server; (2) a Linux operating system (SLES 8); (3) a database (DB2); (4) a WebSphere Portal Server; and (5) a Cisco router.
Such prior art situation for the provisioning of business applications is sketched in FIG. 1. It will be described next including its disadvantages:
An application client 110, as mentioned above, comprises some hardware and software and some operatively working network connections in between in order to run a business application provisioned by an application provider 130, when a respective external request to provision, 120, is transferred via network to the application provider. At the application provider side a networked environment is present and maintained, which includes the following blocks of components:
First, an application environment is provided by the application provider side 130. It comprises networked resources as follows:
On some Intel PC hardware (HW) machine 144 a Windows operating system 142, for example Windows NT, is installed in order to operate a load balancer application 140. On a second hardware machine 154, for example an IBM PowerPC, the AIX operating system 152 is implemented to run some application server software 150. Then, on an IBM mainframe hardware machine 164 runs a Linux operating system 162 in order to run a database software application 166, which serves to perform the business process desired by the application client 110.
Second, a distributed resource manager 170 is a software component as mentioned above and implemented on some server hardware. It comprises a predefined list 172 of valid resource combinations, which can be interconnected and serve to run the business application for application client 110. In order to do so the application provider 130 may access and use a multitude 180 of resources 181, 183, 185, 186, which are interconnected into cooperating resource combinations in order to make the business application run in full functionality and with a minimum of hardware or software errors in order to guaranty the best possible quality of service to the client.
In the prior art software product mentioned above which is implemented in the component 170 in FIG. 1, the list of valid resource combinations 172 is created by manual work, done by staff members at the application provider side, for example in form of XML files, in which each entry of the list comprises a valid resource combination and the date of the last successful instantiation or invocation of the resource combination. Further, scripts are required for controlling the resources. Any interdependencies between resources must be programmed in those scripts. Due to the complexity of interdependencies between resources in prior art, it is very difficult to create combinations of resources across system borders. Each resource is monitored separately. If a resource fails and a restart is no more possible within the current system, the whole group of cooperating resources comprised of such combination is moved onto a standby system, which is maintained separately exactly for such so-called “fail over” situations. The disadvantage associated therewith is that redundant, mirrored fail over systems must be maintained in order to guarantee quality of service. In this context, a typical system would be an Intel PC with an adequate operating system and an Oracle database. Another system might be IBM server and a DB2 relational database. In the above-mentioned IBM software product Automation Manager, such above-mentioned interdependencies are defined by way of a set of abstract rules. The prior art resource manager guarantees that these interdependencies and other constraints, which may be added by staff, are satisfied.
In this prior art product the case is included in which resources of a defined combination are distributed over multiple systems. A further disadvantage of this prior art is, however, that those rules must be very detailed and precise, in particular the last mentioned cross-system-borders cases, as for example, untypical combinations like Intel PC and DB2 database, or an IBM Server plus Oracle database. If such detailed level is not present, the whole system must be replaced when only one component thereof fails.
Thus, the term “system” is to be understood herein with some degree of generality, and a system can be a single hardware server that is used to provide an application service. But for a more complex application, multiple servers in one location have to be considered as a single system that cooperates to accomplish the service for a specific application.
All resources are monitored separately and the working status of the combination yields directly as an AND connection of the respective resources. This concept relies on the assumption that, if all resources comprised of a given combination do work, the overall system required for some business process in a given business application will also work. This, however, is erroneous as daily experiences show.
The prior art fail over concept comprises some disadvantages, described as follows: due to complex configurations of resources including multiple patch levels, multiple user authorisations, modifications within a network, exchange of hardware components, possibly modifying a hardware license key and last but not least the progressive update in software versions, the fail over process provided by prior art does not work in a satisfying way, which is intolerable with the aim of high quality of service.
In view of the difficulties and disadvantages of prior art the present invention was built up.
It is thus an objective of the present invention to improve prior art method and system of resource selection.